Micro Frontends
In recent years, headless architectures have gained significant popularity and are increasingly becoming the norm for brands seeking to create outstanding customer experiences. By decoupling the frontend layer from the backend, headless commerce offers the advantage of faster, more scalable, and more secure websites. However, headless backends still use monolithic architectures, which have limited flexibility. Therefore, headless commerce has evolved into composable commerce, a design approach that divides the backend into multiple specialized business capabilities, each provided by one or more microservices (MS) that are usually orchestrated by a Backend For Frontend (BFF).
Microservices are more capable and offer greater flexibility to develop new features compared to their monolithic counterparts due to their specialization. This results in an improved customer experience.
The current trend is to build a feature-rich and powerful single page application, which sits on top of a microservice architecture. However, the frontend of the application still remains monolithic, which reduces the advantages of microservices. This is because everything is tightly coupled, and every upgrade requires redeploying the entire application.
To address this, a new architectural style called micro frontends (MFEs) has emerged. It extends the composable nature of microservices to the user interface, enabling a website or web app to be viewed as a set of self-contained features.
tl:dr
As our site grows, the time and complexity required to build and maintain grows as well. To keep our site and builds fast, we are going to be breaking our applications into smaller, more focused microsites. Now we have the flexibility to use redirects or proxies to recombine them to provide a seamless web experience for our customers.
Domains
Here we have two options based on whether we want to use subdomains or URL paths for different sections of our site.
Redirects
Currently Cloudflare own our domain. Because of this and Vercel not having the flexibility our only option is to use subdomains / redirects.
- We have the main www domain for the landing page of the site - www.rapha.cc
- Each microsite has a custom subdomain
- content.rapha.cc
- search.rapha.cc
- auth.rapha.cc
- Each of these subdomains are hosted on High Performance Edge Network
- We redirect customers from 1 domain to the other using Cloudflare redirects
Proxies
If we don't want to have subdomains per section of the site, we can still populate content or search by proxying content from each microsite
- We have the main www domain for the landing page of the site - www.rapha.cc
- Our other microsites still retain their subdomain
- content.rapha.cc
- search.rapha.cc
- auth.rapha.cc
- We host the main www on High Performance Edge Network
As customers navigate to different paths such as www.rapha.cc/content, the content from Alderaan will be proxied to them.
Benefits
Micro frontends are a cutting-edge architectural style in modern web development that combines the benefits of microservices and Jamstack. This approach offers many advantages, as well as some challenges, which are detailed below.
- Accelerated time-to-market
Unlike monolithic websites, micro frontends are individual, deployable applications that can be managed by independent squads. Eliminating dependencies simplifies the release management cycle, making it easier and faster to ship new features.
- Simplified code bases
Micro frontends feature smaller code bases that are easier to develop, maintain, and test. Since each micro frontend can be developed separately, there is a lower risk of unintended coupling between components, resulting in cleaner code, separation of concerns and less technical debt.
- Improved error isolation
Decoupled code bases and independent development squads make debugging faster and more straightforward. Bug fixing on one micro frontend does not affect the rest of the website, which can continue to be deployed independently.
- Ease of implementation
Micro frontends are reusable apps that can be embedded in multiple websites, saving time and reducing the need to reinvent the wheel. They can be thought of as a set of reusable micro-experiences that can be shared across different projects. An example of this is our to-be Search application.
- No framework lock-in
One advantage of using micro frontends is that we can develop them using different technologies and frameworks, and still integrate them into a cohesive digital product. This allows for greater flexibility as each team can use their preferred programming language. While it's generally recommended to minimize the number of technologies used and share common patterns, which as an organisation we do, the framework-agnostic approach of micro frontends provides future-proofing for our tech stack and allows developers the freedom to experiment with new tools without being limited to a specific langauges and frameworks.
- Incremental upgrades
Many brands often feel compelled to completely overhaul their legacy code, even if it is barely functional. However, this approach of big-bang rewrites is rarely the best choice. Instead, it is often better to progress incrementally, as this reduces the risk of modernization and ensures business continuity.
Challenges
As with any technology, micro frontend architecture has its own challenges;
- Visual consistency
Maintaining visual consistency is another critical factor to consider. Developing a library of shared and reusable UI components is essential to ensure everyone uses the same design system, resulting in a consistent look and feel across the website. This was one of the first things we tackled when thinking about how to move away from Hybris and have had an active component library since 2019.
- Cross-application communication
Our recommendation is to minimize communication between micro frontends, as it can lead to unintended coupling. However, in some cases, cross-app communication is necessary for building complex web application. The key is to maintain independence between micro frontends. Sharing state or having a shared database is not a good practice for micro frontends. Instead, micro frontends should communicate by exchanging messages or events to preserve their autonomy.
- Shared functionality
It goes without saying that some code will be used universally within micro frontends. A prime example of this is how we serve microcopy, implement seo or render images. Because of this it is necessary to abstract functionality into reusable packages so they can be easily and quickly implemented throughout our technical estate.